(1) Field of the Invention
The present invention relates a video data transmission/reception system composed of a transmission-side and a reception-side, and in which the transmission-side transmits image data that has been compressed using motion compensation interframe prediction to the reception-side, and the reception-side decodes and displays the video data.
(2) Related Art
In recent years services that provide video data to users over the Internet are becoming common with the spread of broadband networks such as ADSL and FTTH. This video data is provided in a compressed form in order to reduce the amount of data, and one of the commonly used methods for such compression is that specified by MPEG-4. In this method, the amount of data is compressed by encoding using combinations of intraframe/interframe encoding and motion compensation prediction.
One form of this kind of video data provision service is a broadcast-type service (in which a transmission-side apparatus distributes the same video data (broadcast video data) to a plurality of user terminals at the same time following a predetermined timetable). Data provision in a broadcast-type service is performed through either a broadcast or a multicast called one-to-many communication. Since individual processing for different users is unnecessary in this method, the number of user terminals that are transmitted to can be increased without extra load on the transmission-side apparatus.
However, services are being diversified, and one type of such diversification is on-demand-type data distribution where, in addition to simply distributing broadcast video data one-sidedly from the transmission-side apparatus, different video data is distributed to individual user terminals in response to individual requests from the user terminals (on-demand data distribution).
One example of such a service is, if the broadcast video data being transmitted is a sports program, transmitting to a particular user terminal past data relating to a particular player as appropriate, in response to a request from the user terminal.
There are a number of methods that can be used for treating broadcast video data when transmitting on-demand video data to a particular user terminal while transmitting broadcast video data.
One method is to continue to transmit broadcast video data to the user terminal while transmitting the on-demand video data. With this method the load on the user terminal is heavy because, in addition to the user terminal requiring sufficient communication band to be able to receive two types of video data simultaneously, the user terminal must also perform extra processing to decode the received video data, such as selective decoding and playing back. For this reason, it is common to use a method whereby transmission of the broadcast video data to the user terminal is interrupted during transmission of the on-demand video data, and only the on-demand video data is transmitted.
However, when transmission of broadcast video data is interrupted for a reason such as transmission of on-demand video data, the following problem arises directly after transmission of the broadcast video data resumes. Specifically, a period of time in which video is not displayed occurs because the user terminal is unable to decode the broadcast video data transmitted directly after resuming transmission. The cause of this lies in the video data compression method (motion compensation interframe prediction). The following describes how this problems arises, with reference to a drawing.
FIG. 1 is a schematic diagram showing how video data is received by a user terminal in Internet broadcasting in a case in which transmission of broadcast video data is interrupted and on-demand video data is transmitted. Here, reception of broadcast video data 111 is interrupted at a time t0, and on-demand video data 112 is received instead until a time t1. Reception of the broadcast video data is then resumed at the time t1. The broadcast video data 111 is compressed according to a method whereby one I frame (intraframe compressed frame) of 30 frame/sec video is provided every five seconds. Accordingly, one unit (GOP: Group of Picture) consists of 150 frames, one of which is an I frame. The ratio of I frames is low in Internet broadcasting compared to digital broadcasting (two I frames per second of 30 frame/sec video).
In FIG. 1, a GOP 1110 is the GOP in the broadcast video data 111 that is received over a period of time that includes the time t1. The GOP 1110 is composed of one I frame and a plurality of P and B frames, as are other GOPs. Each GOP is interframe encoded so that each P frame uses a nearest preceding I or P frame as a reference frame, and each B frame uses preceding and subsequent I or P frames as a reference frames.
Since transmission of the top three frames in the GOP 1110, which include the I frame, overlaps with transmission of the on-demand video data, the user terminal does not receive these three frames. For this reason, the fourth frame, which is a P frame encoded so as to use the head I frame as the reference frame, cannot be decoded. In addition, the P and B frames subsequent to the fourth frame are also unable to be decoded because they refer to the fourth frame. As a result, the video that corresponds to the P and B frames from the fourth frame onwards is not correctly displayed. This situation continues for as many as 149 frames' worth of broadcast video data (just under 5 seconds) if the broadcast video data has been encoded using the method where one I frame of 30 frame/sec broadcast video data is provided every 5 seconds (in the case of video data encoded at two I frames per second display stops for 14 frames' worth (just under 0.5 seconds)).
Possible ways of preventing this problem include (1) continuing transmission of broadcast video data during on-demand video data transmission, and having both types of video data decoded in parallel in the user terminal, and (2) having the transmission apparatus stagger transmission of the broadcast video data to the particular user terminal only, and reorganize and re-encode the GOP to include an I frame as the first frame directly after resumption, so that I frame data is always received first on resumption of transmission. However, the method described in (1) requires a wider band and increases the processing load of the user terminal, while the method described in (2) increases the load in the transmission-side apparatus because the apparatus must perform extra processing to treat the user terminal that receives the on-demand video data differently from other user terminals. This load increases as the number of user terminals that simultaneously receive on-demand video increases. This potentially leads to a problem of limiting the number of users who can be broadcast to simultaneously.